I get some weird runtime warnings in the isfinite and isinf ufuncs:

tests/test_quaddtype.py: 10 warnings
  /workspaces/numpy-user-dtypes/quaddtype/tests/test_quaddtype.py:113: RuntimeWarning: invalid value encountered in isfinite
    quad_result = op_func(quad_val)

tests/test_quaddtype.py: 10 warnings
  /workspaces/numpy-user-dtypes/quaddtype/tests/test_quaddtype.py:113: RuntimeWarning: invalid value encountered in isinf
    quad_result = op_func(quad_val)

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html

Any idea what I'm doing wrong?

IEEE says comparisons with NaNs trigger FPEs (floating point error; FPEs are a flag set on the CPU when one occurs basically). That means normally also nan == inf.
C99 has special comparison functions for this purpose (not that all compilers used to get it right). Maybe sleef gets these warnings right, maybe not. But the best solution would be to avoid the function triggering it. Maybe sleef has a quiet comparison or just a way to test for this without a comparison.

IEEE says comparisons with NaNs trigger FPEs (floating point error; FPEs are a flag set on the CPU when one occurs basically). That means normally also nan == inf. C99 has special comparison functions for this purpose (not that all compilers used to get it right). Maybe sleef gets these warnings right, maybe not. But the best solution would be to avoid the function triggering it. Maybe sleef has a quiet comparison or just a way to test for this without a comparison.

This definitely got me on the right track but wasn't the issue in the end. In fact, Sleef_cast_from_doubleq1(std::numeric_limits<double>::infinity()) raised the flag (no idea why), so I switched to using constants defined with sleef_q (the recommended way).

Seems plausible that the sleef casts uses the wrong type of comparisons internally and nobody noticed/cares (or the compilers mess it up later).

@juntyr one thing I forgot is, that we should definitely add -ftrapping-math (compare NumPy meson.build for Clang builds. The default is just terrible for NumPy here since it honors FPEs (NumPy does, clang doesn't). If you were using Clang, it may well be that just setting this flag fixes the issue. (We should set it either way.)

@SwayamInSync I've rebased this PR and it should now also be good to go

Thanks @juntyr